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(54) Utilizing internet protocol mobility messages and authentication, authorization and 
accounting messages in a communication system 



(57) A system and method for utilizing internet pro- 
tocol (IP) mobilily messages and aulhenlication, author- 
ization, and accounting (AAA) messages in a commu- 
nication system is presented. The communication sys- 
tem comprises a data network coupled to a visited net- 
work, a home network, and a service broker, where the 
visited network and the home network are each coupled 
to an access node. A serving mobility manager (SMM), 
which is located in the visited network, receives a user 
request for information via the access node. A local 
AAA, which is coupled to the SMM and located in the 
visited network, queries the service broker to determine 
the user's home network. The service broker is coupled 



to the visited network and the home network. A service 
broker AAA server, which is located in the service bro- 
ker, contacts a home AAA server, which is located in the 
home network. The service broker AAA server estab- 
lishes a trust relationship between the visited network 
and the home network by utilizing an extension of the 
IP mobility messages. These IP mobility extension mes- 
sages are combined with the AAA messages to provide 
mobility functionality to the AAA messages. A home mo- 
bility manager (HMM), which is coupled to the home 
AAA server and is located in the home network, trans- 
mits to the userthe information via the data network, the 
SMM, and the access node using the trust relationship. 
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Description 

[0001] This application relates generally to utilizing internet protocol (IP) mobility messages and, more particularly, 
to utilizing an extension of the IP mobility messages to provide mobility functionality to Authentication, Authorization, 

5 and Accounting (AAA) messages. 

[0002] The Internet Engineering Task Force (IETF) standards body has defined one AAA protocol called RADIUS 
and is currently defining another AAA protocol called DIAMETER. 

Radius is a distributed security system which uses an authentication server to solve the security problems as- 
sociated with remote computing. Distributed security separates user authentication and authorization from the com- 

10 munications process and creates a single, central location for user authentication data. Also, distributed security is a 
client/server approach which allows a number of communication servers, or clients, to authenticate a dial-in user's 
identity through a single, central database, or authentication server, which stores all information about users, their 
passwords, and access privileges. Distributed security is better than other types of security because of the central 
location for authentication data which makes it more secure than scattering information on different devices throughout 

15 a network. It is also scalable, which makes it conform to customers' client needs, and it is easier to manage with all 
the data in one, secure place. 

Although Radius provides distributed security to a network, it has a number of limitations. Since Radius is not 
extensible, a limited amount of information can be transmitted via the Radius AAA messages. Additionally, mobility is 
not supported. 

20 Diameter is an application layer protocol which provides a unified means for carrying different types of messages. 

Diameter consists of a base protocol and extensions that can be built on top of this base for specific tasks such as 
resource management and accounting extensions that provide functionality related to AAA as well as other services. 
For example, as the number of new internet services has increased, routers and network access servers have had to 
undergo re-engineering to support them. These new services could often benefit from a AAA protocol to facilitate off- 

25 loading policy information to an external server. 

An example of such a service is dial-up internet access. Large internet service providers cannot bearthe admin- 
istrative burden to configure all of their users on each network access server every time a new device is deployed. In 
this scenario, Radius has been used successfully by many such internet service providers. New services such as Voice 
over IP, Fax over IP, and Mobile IP also require similar services in order to be able to authenticate, retrieve authorization 

30 information, and generate accounting records for billing purposes. A problem occurs when each service has its own 
policy protocol defined. This requires customers to deploy several policy servers, which increases the cost of admin- 
istration and complicates deployment. Diameter offers a common solution by defining a base protocol that defines 
header formats (which are followed by objects), security extensions and requirements as well as a small number of 
mandatory commands and Attribute- Value-Pairs (AVPs). The AVPs are headers in which the objects are encapsulated. 

35 New services can extend Diameter by extending the base protocol to support new functionality. 

Diameter, which is an evolution of Radius resolves some of the shortcomings of Radius and also offers a protocol 
that is extensible. Diameter does not, however, support mobility. 

An IETF protocol known as Mobile IP supports mobility in IP networks through the use of datagrams. Information 
in an IP network is transferred as a sequence of datagrams which are collections of data that are sent as a single 

40 message. Each of these datagrams is sent through the network individually. Initially, a datagram, which is about to be 
delivered to a mobile node, arrives at a home network via standard IP routing. The datagram is then intercepted by a 
home agent and tunneled to a Care-Of-Address. The datagram is then detunneled and delivered to the mobile node. 
For datagrams sent by the mobile node, standard IP routing delivers each datagram to its destination. Although the 
Mobile IP protocol provides mobility functionality, it does not provide AAA functionality. 

45 [0003] Certain IP networks include various entities (such as mobility managers and AAA servers) that need to com- 
municate with different administrative domains or networks in various situations such as, for example, during a handoff . 
In such a scenario, both a handoff request and an authentication request will be made as the mobile node moves from 
one network to another. Thus, the Mobile IP protocol is best positioned to provide the mobility functionality (the handoff 
request) while the Diameter protocol is best positioned to provide the AAA functionality (the authentication). Utilizing 

so both protocols results in various network limitations. For example, network delays may be experienced because two 
different protocols and thus two different sets of messages must be used to provide service to a roaming user. Further 
network capacity may be constrained because of design complexities associated with utilizing two different protocols. 

Therefore, what is needed is a protocol that reduces or eliminates these limitations and design complexities by 
extending the IP mobility messages, where these IP mobility extension messages are combined with the AAA messages 

55 to provide mobility functionality to the AAA messages. 

[0004] In response to these and other limitations, provided herein is a unique system and method for utilizing internet 
protocol (IP) mobility messages and Authentication, Authorization, and Accounting (AAA) messages in a communica- 
tion system. The communication system comprises a data network coupled to a visited network, a home network, and 
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a service broker, where the visited network and the home network are each coupled to an access node. In one em- 
bodiment, a Serving Mobility Manager (SMM), which is located in the visited network, receives a user request for 
information via the access node. A local AAA, which is coupled to the SMM and located in the visited network, queries 
the service broker to determine the user's home network. The service broker is coupled to the visited network and the 

5 home network. A service broker AAA server, which is located in the service broker, contacts a home AAA server, which 
is located in the home network. The service broker AAA server establishes a trust relationship between the visited 
network and the home network by utilizing an extension of the IP mobility messages. These IP mobility extension 
messages are combined with the AAA messages to provide mobility functionality to the AAA messages. A home mobility 
manager (HMM), which is coupled to the home AAA server and is located in the home network, transmits to the user 

10 the information via the data network, the SMM, and the access node using the trust relationship. 

In some embodiments, the visited network queries the user's home network, via a pre-configured trust relation- 
ship. 

In some embodiments, the visited network dynamically establishes (without a trust relationship) a relationship 
with the home network by utilizing the extension of the IP mobility messages. 
15 In some embodiments, the user request is transmitted via a plurality of access protocols. 

In some embodiments, the IP mobility extension messages comprise base AAA headers, message specific at- 
tribute value pairs, and message specific parameters. 

In some embodiments, the IP mobility extension messages are created in the SMM. 
In some embodiments, the IP mobility extension messages are created in the HMM. 
20 [0005] Examples of the invention will now be described in detail with reference tothe accompanying drawings, in 
which: 

Fig. 1 is a diagrammatic view of a communication system of the present invention. 

Fig. 2 is a diagrammatic view of the communication system of the present invention that depicts the transmission 
25 of IP mobility messages on the AAA protocol. 

Fig. 3 is a diagrammatic view of the communication system of the present invention that depicts the transmission 
of user requested information via the IP mobility messages on the AAA protocol. 

Fig. 4 is a message flow of an Initial Registration where the mobile node is configured with a routable IP Address. 

Fig. 5 is a message flow of an Initial Registration where the mobile node and the user's home network are configured 
30 with a non-routable IP Address. 

Fig. 6 is a message flow of an Initial Registration where the mobile node does not have an IP Address and where 

the mobile node and the user's home network are configured with non-routable IP addresses. 

Fig. 7 is a message flow of an Initial Registration with hierarchical routers. 

Fig. 8 is a message flow of a mobile node moving to a new routing area on a new LSF. 
35 Fig. 9 is a message flow of the mobile node moving to a new routing area 

Fig. 10 is a message flow of a user roaming between routing areas within the same xAN/LSF. 

Fig. 1 1 is a message flow of a user roaming to a new routing area where the mobile node's COA does not change. 

Fig. 12 is a message flow of a user roaming back into their home network, where the network is a combined LSF/ 

NSF. 

40 Fig. 13 is a message flow of a user roaming between LSFs where the mobile node does not send a registration 

request message to the old LSF that indicates the the mobile node is about to move. 

Fig. 14 is a message flow of a user terminating a connection to their service provider. 

Fig. 15 is a message flow of a handoff between two LSFs. 

Fig. 1 6 is a message flow of a handoff between two xANs on the same LSF. 
45 Fig. 1 7 is a message flow of a handoff between two xANs on the same LSF. 

Fig. 1 8 is a diagrammatic view of a computer of the present invention. 

Fig. 19 is a flow chart of a method of the present invention for utilizing IP mobility messages and AAA messages. 

[0006] Fig. 1 depicts a communication network (or system) 1 0 of the present invention that utilizes internet protocol 
so (IP) mobility messages and Authentication, Authorization, and Accounting (AAA) messages. The network 10 includes 
a data network (such as the Internet) 12 that is coupled to a visited network 14. a user's 24 home network 16, and a 
service broker 18. The visited network 14 (or Local Serving Function (LSF)) and the home network 16 (or Network 
Serving Function (NSF)) are each coupled to an access node 20 which may be, for example, a remote access network 
or a dial-up modem. The access node 20 transmits messages between a mobile station (or mobile node) 22 and the 
55 various entities 1 2-1 8 in network 1 0. The messages perform certain functionality related to the user's 24 requests. 

The messaging transmitted in the network 1 0 extends the functionality of AAA (originally designed for authenti- 
cation, authorization, and accounting) to accomplish seamless mobility. The mobility extension to the AAA protocol is 
for the control plane messaging of the architecture. In current wireless networks, IS41 and MAP are the messaging 
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protocols used for mobility and exist on top of SS7. AAA with the mobility extension will serve the same purpose in IP 
centric networks. 

The LSF 14 is the serving area network and is the entity that permits the mobile station 22 to obtain access to 
the network 1 0. The NSF 1 6 is the home network of the mobile station 22 and is the entity where the user's 24 sub- 

5 scription exists. Control plane messaging to accomplish mobility between the LSF 1 4 and the NSF 1 6 is performed via 
AAA servers 30 (which are shown with a + denoting the fact that the mobility is performed by the AAA servers 30 using 
the IP mobility extension messages of the present invention). The AAA servers 30 provide a secure means of com- 
munication between the LSF 14 and NSF 16. The AAA server 30 itself does not have the capability to perform any 
specific task such as authentication or mobility. It is responsible for delivering or routing the messages to the appropriate 

10 entity that performs the specified task. 

In the IP mobility architecture of the present invention, the mobility functions in the LSF 14 are performed by the 
Serving Mobility Manager (SMM) 26 and in the NSF 16 by the Home Mobility Manager (HMM) 28. Mobility messages 
are exchanged between SMM 26 and the HMM 28 (via the routers 34) in order to provide network access to a mobile 
user. An example of a mobility message exchanged between the SMM 26 and the HMM 28 is a Registration message. 

15 This message is constructed via the mobility extension to AAA of the present invention. This implies that a Registration 
message includes the base AAA headers and the Registration specific information defined by the mobility extension. 
The SMM 26 and the HMM 28 each relay messages to their AAA server 30 and rely on it 30 to perform delivery 
functionality. The message is routed to a particular AAA server based on the message type or on the user's 24 Network 
Access Identifier (NAI) which is similar to an email address. Since mobility control plane messages are delay sensitive, 

20 the choice of the transport protocol that the base AAA runs on is quite critical. The I P mobility architecture is a functional 
architecture and does not assign the task of the SMM 26 or HMM 28 to any specific platform. Hence, the SMM 26, 
HMM 28, and the AAA servers 30 can be distributed across various platforms in the network 1 0. 

The AAA server 30 in NSF 16 also interfaces to an authentication server or center 36 that is responsible for 
authenticating the mobile station 22. AAA servers may interface to multiple other AAA servers via trust relationships 

25 or via service level agreements (SLAs). A trust relationship is established by the AAA server 30 in the service broker 
18 when it 30 contacts the NSF 16. The trust relationship ensures that the messages are being transmitted over a 
secure path. After the trust relationship has been established between the LSF 14 and the NSF 16, subsequent mes- 
sages to and from the LSF 1 4 and the NSF 1 6, do not need to establish another trust relationship via the service broker 
18. Further, the trust relationship may be pre-configured. 

30 A SLA may be established without the use of a service broker 18. As such, the LSF 14 dynamically establishes 

a relationship (without trust) with the NSF 16. In either scenario (trust relationship or SLA), the extension of the IP 
mobility messages of the present invention may be used. It is the responsibility of the AAA server to resolve the ap- 
propriate server to send the mobility messages to. 

The functional elements performed by the AAA servers 30 include: proxying, message routing, interaction with 

35 the service broker 18, and security. 

AAA servers 30 act as proxies for various network elements such as the SMM 26 and HMM 28. The term proxying 
is used when the AAA server 30 simply relays messages from one server to another. In the case of the AAA server in 
the LSF 1 4, it 30 plays the role of a proxy server to the SMM 26 for messages that are sent to the HMM 1 6 or to an 
authentication center elsewhere in the network. The proxy server takes on the task of relaying the message to the 

40 appropriate entity in the network from the SMM 26 or the HMM 28 where it can be processed. The proxy AAA server 
in the LSF 14 and the NSF 16 are responsible for making the routing decisions. The SMM 26 and the HMM 28 do not 
have to maintain information regarding the endpoints for delivery of messages. Rather, they interact with and permit 
their local AAA server to routing the messages to the appropriate entities. 

The SMM 26 and HMM 28 communicate using the AAA servers that are local to them. The SMM 26 or HMM 28 

45 messages do not have the IP address of their destination. Ratherthe destination address for messages from the SMM 
or the HMM is the IP address of the local AAA server that they are configured with. The IP mobility messages are 
proxied by AAA servers in the network and delivered to their final destination. The AAA servers 30 use the NAI Attribute- 
Value-Pair (AVP) contained in the messages and also the proxy state AVP for routing. The AVP contains an attribute 
code and its value. 

so The AAA server 30 in the LSF 14 may be configured with the address of the AAA server 30 in the NSF 16 with 

which it has a service/roaming agreement. However from a scalability perspective, it is impractical that the AAA server 
in the LSF 1 4 will have a SLA with every other AAA server belonging to different service provider NSFs. Thus, service 
brokers 18 will establish SLAs with multiple service providers and other service brokers. An LSF, by establishing an 
SLA with a service broker, is able to indirectly establish SLAs with all other service providers that have agreements 

55 with the broker. When a mobility message of the present invention arrives at the AAA server and the server does not 
have an SLA with the domain that the message is destined for, then the AAA server may forward the message to a 
service broker 1 8 who may have an SLA with the domain associated with the message being sent. 

Communication between AAA servers occurs over IPsec tunnels. Hence the AAA server provides security to 
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messages that are exchanged between the LSF and NSF. IPsec is a network layer security mechanism that the AAA 
protocol, which is an application layer protocol, is unaware of. IPsec Securitry Asociations (SAs) are established be- 
tween the AAA servers at the time an SLA is established between the two networks. Between the AAA servers in the 
LSF and the NSF or the service broker, transport mode security using an Authentication Header is used. The Security 

5 Gateways 32 at the edge of the network may have tunnel mode Encapsulating Security Payload (ESP) between the 
networks. The AAA servers may have both transport mode Authentication Headers and tunnel mode ESP. 

Fig.'s 2 and 3 generically depict the transmission of the IP Mobility extension messages. The SMM 26 receives, 
via the access node 20, a user 24 request for information. The user request may be transmitted via a plurality of access 
protocols such as TDMA, CDMA, etc. The local AAA server queries the service broker 1 8 to determine the user's 24 

10 home network. The service broker's 1 8 AAA server 30 contacts the home 1 6 AAA server. The service broker's 1 8 AAA 
server 30 establishes a trust relationship between the visited network and the home network by utilizing an extension 
of the IP mobility messages, where the IP mobility extension messages are combined with the AAA messages to 
provide mobility functionality to the AAA messages. The HMM 28 then transmits to the user 24, the information via the 
data network 12, the SMM 26, and the access node 20 using the trust relationship. 

15 The IP mobility extension messages comprise base AAA headers, message specific attribute value pairs (AVPs), 

and message specific parameters, and may be created in the SMM and in the HMM. 

The mobile IP extension of the AAA protocol defines a method that allows a mobile station 22 to change its point 
of attachment to the Internet 12 without service disruption. Mobile IP is an extension to the Diameter server that allows 
cross-domain authentication and authorization, assignment of a mobile station's home address, assignment of a Home 

20 Agent, and key distribution to provide mobile IP services in a large network. 

[0007] The IP Mobility extension of the present invention defines the messages and AVPs to support mobility in the 
IP Mobility Architecture. These IP Mobility extension messages, which run on top of the base AAA protocol, are pre- 
sented below: 

25 Registration Messages 

[0008] 

I. Registration Request 
30 2. Registration Response 

3. Registration Cancellation 

4. Registration Cancellation Acknowledge 

5. Address Update Request 

6. Address Update Response 

35 

Inter-LSF Messages 
[0009] 

40 7. Context Request 

8. Context Response 

9. Binding Update 

10. Binding Update Response 

45 Proxy/Broker Messages 
[0010] 

II . Discover Request 
so 12. Discover Response 

Other Messages 

[0011] 

55 

13. Correspondent Node List 

14. Correspondent Node List Acknowledge 
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[0012] Table 1 defines the Diameter commands for IP Mobility messages and their respective command codes. A 
Diameter entity supporting IP Mobility Extension supports these commands. 

Table 1 : 



IP Mobility Extension command list 


Command AVP Name 


Command AVP Code 


Registration Request Command 


335 


Registration Response Command 


336 


Context Request Command 


337 


Context Response Command 


338 


Registration Cancellation Command 


339 


Registration Cancellation Ack Command 


340 


Binding Update Command 


341 


Binding Update Response Command 


342 


Correspondent Node List Command 


343 


Correspondent Node List Ack Command 


344 


Discover Request Command 


345 


Discover Response Command 


346 


Address Update Request Command 


347 


Address Update Response Command 


348 



[0013] Table 2 provides the general format of the IPM Command Code AVP, The flag bits P, T, and V must not be 
so set, flag bits E and H may be set depending on the security model used, and flag bit M must be set. 

Table 2: 

IP Mobility Command code format 

35 AVP Code: 256 

AVP length: 12 | Reserved | (P) | (T) | (V) | [E] | [H] | <M> 
Command Code: Any of the above 

40 [0014] Table 3 defines the unique AVPs required for the IP Mobility messages. These AVPs are used in the various 
IP Mobility extension messages that will be described in relation to Fig.'s 4-1 7: 



Table 3: 



New AVPs for IP Mobility Extension 


AVP Name 


AVP Code 


Protocol Version 


361 


LSF NAI 


362 


MS IP Address 


363 


Care Of Address (IP Address) 


364 


Profile type 


365 


Profile 


366 


Terminal Type 


367 


Signal Strength 


368 
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Table 3: (continued) 



New AVPs for IP Mobility Extension 


AVP Name 


AVP Code 


Service Level Request 


369 


Authorization Period (Registration) 


370 


Service Level Information 


371 


CN IP List 


372 


L2 Address of MS 


373 


HMM NAI 


374 


Context Data AVP 


375 


IPM Response Code 


376 


Routing Area 


377 


Registration Type 


378 


Context Request Type 


379 


Source NAI 


380 


Destination NAI 


381 



25 [0015] Table 4 displays the list of AVPs that are included in the IP Mobility architecture: 

Table 4: 



Implementation Status of IP Mobility Extension AVPs 


No 


AVP Name 


1. 


Registration Request Command 


2. 


Registration Response Command 


3. 


Address Update Request Command 


4. 


Address Update Response command 


5. 


Context Request Command 


6. 


Context Response Command 


7. 


Registration Cancellation Command 


8. 


Registration Cancellation Ack Command 


9. 


Binding Update Command 


10. 


Binding Update Response Command 


11. 


Discover Request Command 


12. 


Discover Response Command 


13. 


Correspondent Node List Command 


14. 


Correspondent Node List Ack Command 


15. 


Protocol Version 


16. 


LSF NAI 


17. 


MS IP Address 


18. 


Care Of Address 


19. 


Profile type 
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Table 4: (continued) 



Implementation Status of IP Mobility Extension AVPs 


No 


AVP Name 


20. 


Profile 


21. 


Terminal Type 


22. 


Signal Strength 


23. 


Service Level Request 


24. 


Authorization Period (Registration) 


25. 


Service Level Information 


26. 


CN IP List 


27. 


L2 Address of MS 


28. 


HMM NAI 


29. 


Context Data 


30. 


IPM Response Code 


31. 


Routing Area 


32. 


Registration Type 


33. 


Context Request Type 


34. 


De-Registration Result Code 


35. 


Source NAI 


36. 


Destination NAI 



30 

The IP Mobility extension messages listed in Table 1 are described below: 

[0016] Registration Request - This message is used by the SMM to establish a data packet session with the user's 
home network. This message follows the Authentication procedure. The Registration Request message is sent to the 
35 local AAA server by the SMM, which forwards it to the Home AAA server. The Home AAA server then forwards it to 
the HMM. The Parameters of the Registration Request message are: 

a. User NAI 

b. IP Address of Mobile Node (Home IP Address). 
40 c. LSFNAI 

d. Care of Address of Mobile Node 

e. Profile type 

f. Terminal type 

g. Service Level Request 
45 h. Signal Strength 

i. Protocol version 
j. Destination NAI 
k. Source NAI 
I. Time Stamp 



55 
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<Diameter Header> 
<RR Command AVP> 



<MS IP Address> 



[Care of Address of Mobile Node] 



[Service Level Request] 



<Source NAI> 



{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0017] Registration Response - The HMM 28 generates a Registration Response message in response to a Regis- 
tration RequesL message and sends it to the AAA server at the NSF 1 6, which forwards it to the LSF 1 4 AAA server. 
The LSF 1 4 AAA server then forwards it to the SMM 26. The Parameters of the Registration Response message are: 

a. User NAI 

b. IP Address 

c. Profile 

d. COA Required 



f. Authorization Period 
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<DiameterHeader> 
<Response Command AVP> 



<MS IP Address> 



[Profile] 



[Authorization Period] 



<Time Stamp> 
[Service Level Information] 



<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



25 [0018] Address Update Request - This message is used by the SMM 26 to inform the HMM 28 of the co-located IP 
address assigned to the MN 22. This is necessary if the MN 22 is configured with a non-routable IP address and the 
HMM requested the SMM to allocate a COA in a Registration Response message. This message also needs to be 
sent when the MN 22 is roaming between RAs (Routing Areas). The SMM sends the message to the local AAA server, 
which forwards the message to the Home AAA server. The Home AAA server then forwards it to the HMM 28. The 

30 Parameters of the Address Update Request message are: 

a. User NAI 

b. Co-located COA 

c. Destination NAI 
35 d. Source NAI 

e. Time Stamp 



<AU Command AVP> 
< User NAI > 
[Destination NAI] 
<Source NAI> 
<Time Stamp> 
<Co-located COA> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



55 [0019] Address Update Response - The HMM 28 generates an Address Update Response message in response to 
an Address Update Request message and sends it to the AAA server at the NSF 16, which forwards it to the LSF 14 
AAA server. The LSF 1 4 AAA server then forwards it to the SMM 26. The Parameters of the Address Update Response 
message are: 
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a. User NAI 

b. Response Code 

c. Destination NAI 

d. Source NAI 

e. Time Stamp 



<Diameter Header> 



;<Integrity-Cheok- Vector AVP> || 
<Digital-Signature AVP>} 



[0020] Context Request - The SMM 26 sends the Context Request message to request the MN 22 information (ses- 
sion context information) from the old (previous) LSF 14. The SMM 26 sends this message to the local AAA server, 
which forwards it to the previous LSF 14 AAA server. The previous LSF 14 AAA server then forwards to its SMM 26. 
This message triggers the buffering of data at the previous LSF. The Parameters of the Context Request message are: 

a. Previous LSF NAI 

b. User NAI 

c. L2 Address of MS 

d. Context Request Type 

f. Destination NAI 

g. Source NAI 

h. Time Stamp 



<Diameter Header> 
<CR Command AVP> 
<Previous LSF NAI> 
[Context Request Type] 
< User NAI > 
[Destination NAI] 
<Source NAI> 



<L2 Address of MS> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 
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[0021] Context Response -The previous SMM sends the Context Response message to the current SMM in response 
to the Context Request Message. The SMM sends the Context Response message to the local AAA server, which 
forwards it to the current LSF AAA server. The current LSF AAA server then forwards it to its SMM. The Parameters 
of the Context Response message are: 

a. Current LSF NAI 

b. User NAI 

c. MS IP address 

d. Response Code 

e. Context Data 

f. Destination NAI 

g. Source NAI 

h. Time Stamp 



<Diameter Header> 
<CR Response Command AVP> 



<Current LSF NA1> 



<Response Code AVP> 



<Souree NAI> 



<MS IP Address> 



{<Integrity-Check- Vector AVP> || 
<DigitaI-Signature AVP>} 



[0022] Registration Cancellation - The Registration Cancellation message is used by the HMM 28 to cancel the 
registration of the user 24 at the LSF 14. This message is used when user roams from LSF to LSF. In this scenario, 
the HMM sends the Registration Cancellation message to cancel the registration at the previous LSF. The HMM sends 
the message to the local AAA server, which then forwards it to. The previous LSF AAA server then forwards to its 
SMM. The Parameters of the Registration Cancellation message are: 



a. LSF NAI 

b. User NAI 

c. L2 Address 

45 d. MS IP Address 

e. HMM NAI 

f. Destination NAI 

g. Source NAI 

h. Time Stamp 



55 
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<Diameter Header> 
<RC Command AVP> 



<Current LSF NAI> 



<MS IP Address> 



{<Integrity-Check-Vector AVP> ]j 
<Digital-Signature AVP>} 



[0023] Registration Cancellation Acknowledge - The Registration Cancellation Acknowledge message is sent from 
the LSF 1 4 to the HMM 28 to acknowledge the canceled registration of the user 24. The Parameters of the Registration 
Cancellation Acknowledge message are: 

a. User NAI 

b. Destination NAI 

c. Source NAI 

d. Time Stamp 



<Diameter Header> 
<RC Ack. Command AVP> 



{<Integrity-Check- Vector AVP> [| 
<Digital-Signature AVP>} 



45 

[0024] Binding Update Request - The SMM sends the Forward Packet Request message to request the MS's 22 
buffered packets from the old (previous) LSF. The MM sends the Forward Packet Request message to the local AAA 
server, which forwards it to the previous LSF AAA server. The previous LSF AAA server then forwards it to its SMM. 
This message triggers the forwarding buffered packet to the new MS 22 IP address. The Parameters of the Context 
so Request message are: 

a. LSF NAI 

b. User NAI 

c. MS IP Address 
55 d. Destination NAI 

e. Source NAI 

f. Time Stamp 
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<Diameter Header> 
<FP Request command AVP> 



<MS IP Address> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0025] Binding Update Response - The previous SMM sends the Forward Packet Response message to the current 
25 SMM in response to the Forward Packet Request message. The SMM sends the Forward Packet Response message 
to the local AAA server, which forwards it to the current LSF AAA server. The current LSF AAA server then forwards 
to its SMM. The Parameters of the Forward Packet Response message 

a. User NAI 
30 b. Response Code 

c. Destination NAI 

d. Source NAI 

e. Time Stamp 



<Diameter Header> 
<Binding Update Response Command AVP> 
< User NAI > ~~ 

[Destination NAI] 

________ 

<Time Stamp> 
<Response Code> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0026] Discover Request - The SMM sends the Discover Request message to the Service Broker 1 8 when no SLA 
(Service Level Agreement) exists between the visited network 14 and the user's 24 home network 16. The SMM sends 
the Discover Request message to the local AAA server, which forwards it to the Service Broker's AAA server. The 
55 service broker's AAA server then sends it to the Broker's Manager. The Parameters of Discover Request message are: 

a. User NAI 

b. Destination NAI 
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c. Source NAI 

d. Time Stamp 



<Diameter Header> 



<Discover Request Command AVP> 



{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0027] Discover Response - The Broker Manager, in response to the Discover Request message from the SMM, 
20 sends the Discover Response message. The Broker Manager sends the message to its local AAA server, which sends 
it to the LSF AAA server. The LSF AAA server then sends it to the SMM. The Parameters of Discover Response 
message are: 



a. User NAI 
25 b. HA Address 

c. Shared Keys 

d. Destination NAI 

e. Source NAI 

f. Time Stamp 



<Discover Response Command AVP> 



<Source NAI> 



!<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0028] Correspondent Node List - The Correspondent Node List message is sent from the SMM to the HMM to 
so indicate to the MS 22 the list of corresponding nodes (IP Addresses) that currently have TCP/UDP sessions. The 
Registration Request message is sent to the local AAA server by the SMM, which forwards it to the Home 16 AAA 
server. The Home 1 6 AAA server then forwards it to the HMM. This message invokes the HMM to send binding update 
messages to corresponding nodes. The parameters of the Correspondent Node List message are: 



a. User NAI 

b. Correspondent Node IP List 

c. Destination NAI 

d. Source NAI 
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e. Time Stamp 



<CN List Command AVP> 
<UserNAI> 
[Destination NAI] 



Correspondent Node IP Lisi 



{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0029] Correspondent Node List Acknowledge - The HMM generates the Correspondent Node List Acknowledge 
message in response to the Correspondent Node List message and sends it to the AAA server at the NSF, which 
forwards it to the LSF AAA server. The LSF AAA server then forwards it to the SMM. The parameters of the Corre- 
spondent Node List Acknowledge message are: 

a. User NAI 

b. Response Code 

c. Destination NAI 

d. Source NAI 

e. Time Stamp 



<Diameter Header> 
<CN List Command Ack AVP> 
< User NAI > 
[Destination NAI] 
<Source NAI> 
<Time Stamp> 
Correspondent Node List Result Code> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0030] Address Update Request - The Address Update List Request message is sent from the HMM to the SMM in 
order for the SMM to allocate an address to the MS. The parameters of the Address Update Request message are: 

a. User NAI 
ss b. MS IP Address 

c. Care Of Address 

d. Destination NAI 

e. Source NAI 
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<Diameter Header> 
<Address Update Request Command AVP> 
<MS IP Address> 
<CareOf Address> 

<UserNAI> 
[Destination NAI] 
<Source NAI> 
<Time Stamp> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



20 [0031] Address Update Response - The Address Update List Response message is sent from the SMM to the HMM 
with the allocated MS address in response to the Address Update Request message from the HMM. The parameters 
of the Address Update Response message are: 



g. User NAI 
25 h. Response Code 

i. MS IP Address 
j. Destination NAI 
k. Source NAI 
I. Time Stamp 



<Diameter Header> 
<Address Update Request Command AVP> 
<MS IP Address> 



[Destination NAI] 



<Source NAI> 
<Time Stamp> 
{<Integrity-Check- Vector AVP> || 
<Digital-Signature AVP>} 



[0032] Fig.'s 4-1 7 depict various mobility message flows utilizing the IP mobility messages described above. A few 
observations regarding the message flows include: wireless network access (data) is provided to users that may not 
have a subscription with a specific wireless network provider; a user's home network should create SLAs with all 
55 networks, LSFs and Service Brokers, it wants its users to roam in: IPSec AH and/or ESP are used for security asso- 
ciations; the AAA protocol is used for LSF to LSF and LSF to NSF mobility functions; for private network access, the 
tunneling is layer 3 (IP tunneling); there is no triangle routing unless there is a NSF 'hide the user' policy. Therefore, 
an LSF will maintain COAs for its network. 
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[0033] The message flows describe three various mobility scenarios including user registrations (Fig.'s 4-7), users 
roaming to new routing areas where there are no applications running (no data being transferred) (Fig.'s 8-14), and 
users roaming to new routing areas where there are applications running (handoffs) (Fig.'s 15-17). 
[0034] The message flows assume that: there is at least one router at the edge of the xAN/LSF interface and the IP 

5 router is considered to be part of the xAN; all messages sent between the system components include parameters. 
However, the depicted messages do not include every parameter that will be sent by the originating component. The 
parameters shown are used to help understand the flows; the AAA server located in the LSF has full functionality, i.e., 
it has knowledge of the SLAs between itself and the NSFs and provides a mechanism for determining where a user's 
home AAA server is. It should also be assumed that service agreements have all been pre-established; the xAN's 

10 broadcast control channels are broadcasting the IP address of the SMM, unless otherwise stated; the xANs are chan- 
nelized RANs (such as TDMA) unless otherwise stated; in handoff scenarios for channelized RANs, the RAN will be 
responsible for buffering datagrams that are destined for the MN 22. In unchannelized RANs, the router at the RAN/ 
LSF will be responsible for buffering. 

[0035] The flow in Fig. 4 describes an initial registration where the MN 22 is configured with a routable IP Address. 
15 The user 24 is establishing a packet data session (logging in) to their home network 1 6. The MN 22 is configured with 
a permanent IP address that is associated with the user's home network 16. The home network is configured with 
routable IP addresses. 

[0036] This flow applies to the scenarios when the MS is initially powered on and when a user wants to connect to 
another service provider. It is expected a user wants to establish a connection with their home network when the MN 
20 powers on. This is the concept of 'always on, always ready to receive/send data'. Therefore the MN is configured to 
establish a connection to a particular service provider when the MN powers on. 

[0037] When the user wants to connect to another service provider, they win initiate the connection by accessing a 
user interface or by pushing a pre-configured button on the MN 22 (or by some other means). This process will cause 
the MN to send a Registration Request message to the user's home network. 
25 [0038] After the registration process is completed, the user/LSF is said to have a packet data session established 
with the user's home network. Each message flow is described through the use of alphabetized letters that coincide 
with similar letters in the appropriate figures. The flow begins when: 



a) the user has powered on Ihe MN (or initiated another service provider connection request). The MN is configured 
30 to send a registration message to the user's home network. The registration message is sent to the IP address 

(which is the IP address of the SMM) that was contained in the broadcast control channel (BCCH). The following 
parameters are included in the registration message: 



• The NAI indicates the user who wants to establish the data session. 

• The IPAddr\s the MN's configured permanent IP address. This parameter will not be included if the MN does 
not have a configured IP address. 

• The Profile Type indicates the profile that the user wants to use. The profile may indicate the type of services 
the user has, type of access into the network, etc. 

• The Auth parameter is the user's authentication parameter. In this architecture, it is the user's digital signature. 

• The Terminal Info parameter contains information about capabilities of the terminal, e.g., L2 address, SIP 
supported, H.323 supported, etc. 

• The RegType parameter indicates the type of registration being performed. 

• The RA parameter indicates the name (NAI) of the current subnet point of attachment. The subnet is the logical 
or physical entry in the larger network. 

b) The SMM creates a AAA Authentication Request and forwards it to the LSF's local AAA server. 

c) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
lookup is performed to determine the I P address of the user's home AAA server and the type of security association 
(SA) established between the LSF and NSF. This architecture recommends the use of IPSec authentication (AH) 
for security. The local AAA server will then send the message to the user's home AAA server. Before the packet 
is sent, an IPSec authentication is performed on the message. 

d) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 
performs a lookup to see to which server it should forward the message. Since this is an authentication request, 
it forwards the message to the Authentication Server. 

e) The authentication server authenticates the user. The authentication server may perform several functions, all 
depending on the type of authentication. The architecture recommends the use of digital signatures, so the au- 
thentication server would have received the user's digital signature. In this case, the authentication server would 
consult a directory to acquire the user's public key which it would use to authenticate the user. In this case, the 
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user has been authenticated. The authentication server then creates an authentication response message that 
includes the user's NAI and a flag that indicates the authentication passed. The authentication server then sends 
an authentication response to its home AAA server. It may be possible for the authentication server to send the 
LSF information that will allow the LSFto authenticate the user while the user roams in the LSF. However the LSF 
5 must be able to support the authentication mechanism required by the user. 

f) The home AAA server will create an IPSec AH and send the message to the local AAA server serving the user. 

g) The local AAA server validates the I PSec AH and passes the message on to the SMM . 

h) The SMM now needs to establish the packet data session with the user's home network. This is achieved by 
sending the home network a registration request. The following parameters are added to the registration message: 

10 

• The LSF Info will contain information about the LSF and user mobility. 

• The COA is the IP address that is used by the home network router and correspondent nodes to tunnel dat- 
agrams to the MN/LSF. There is an indication of the type of COA (a router COA or the MN co-located COA). 

15 i) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 

lookup is performed to determine the I P address of the user's home AAA server and the type of security association 
(SA) established between the LSF and NSF. The local AAA server will then send the message to the user's home 
AAA server. Before the packet is sent, an IPSec authentication (AH) is performed on the message, 
j) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 

20 performs a lookup to see what server it should forward the message to. Since this is a registration request, it 

forwards the message to the HMM. 
k) The HMM will perform the following functions: 

• Update the local directory with the LSF and mobility info. 

25 • Send a route update message to the local router so it can update the MN's IP address and COA. 

• The HMM then creates a registration response message that includes the user's NAI and the user's profile. 
The profile will contain, at a minimum, the max bandwidth to be allocated to the user. The HMM then sends 
the registration response to its home AAA server, 

30 I) The AAA server will create an IPSec AH and send the message to the local AAA server serving the user, 

m) The local AAA server validates the IPSec AH and passes the message on to the SMM. 
n) The SMM informs the xAN of User's NAI, User's IP address and MN's layer 2 address. The xAN uses this 
information to route information to the MN. 

o) The SMM will update its local directory with the appropriate info. It will also update the policy database with the 
35 user's max bandwidth allowed. The SMM may create an encryption key to be used by the user's MN for over the 

air encryption. The SMM will send a registration reply to a mobility agent on the xAN/LSF router, 
p) The mobility agent atthexAN/LSF router must update the router's routing table to include the MN's IP address. 
The xAN must be told of the 'binding' between the MN's IP Address and the MN's L2 Address. The mobility agent 
then sends the registration reply to the MN. 

[0039] The flow in Fig. 5 describes an Initial Registration where the MN and the user's home network are configured 
with a non-routable IP Address. The main difference between this flow and the flow associated with Fig. 4 is that the 
MN must be allocated a co-located COA, i.e., an IP address that can be used nodes on the internet to tunnel datagrams 
directly to the MN. 

45 [0040] This flow also applies to the scenarios when the MN initially powers on and when the user wants to connect 
to another service provider. 

[0041] The user has powered on the MN (or initiated another service provider connection request). The MN is con- 
figured to send a Registration message to the user's home network. The Registration message is sent to the IP address 
(which is the IP address of the SMM) that was contained in the BCCH. 

a) The authentication procedure is performed. 

b) The SMM now needs to establish the packet data session with the user's home network. This is achieved by 
sending the home network a registration request. The following parameters are added to the registration message: 

55 • The LSF Info will contain information about the LSF and user mobility. 

• The COA is the IP address that is used by the home network router and correspondent nodes to tunnel dat- 
agrams to the MN/LSF. There is an indication of the type of COA (not co-located). 
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c) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
lookup is performed to determine the I P address of the user's home AAA server and the type of security association 
(SA) established between the LSF and NSF. The local AAA server will then send the message to the user's home 
AAA server. Before the packet is sent, an IPSec authentication (AH) is performed on the message. 
5 d) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 

performs a lookup to see what server it should forward the message to. Since this is a registration request, it 
forwards the message to the HMM. 

e) The HMM will perform the following functions: 

10 • Update the local directory with the LSF and mobility info. 

• The HMM realizes that the COA is not a MN co-located COA which is necessary for MN's that are associated 
with private networks with non-routable I P addresses. The HMM then creates a registration response message 
that includes the user's NAI, the user's profile, and an indication that a MN co-located COA must be allocated. 
The HMM then sends the registration response to its home AAA server and a request for a co-located IP 

15 address. The HMM then sends the registration response to its home AAA server. 

f) The AAA server will create an IPSec AH and send the message to the local AAA server serving the user. 

g) The local AAA server validates the I PSec AH and passes the message on to the SMM . 

h) The SMM will update its local directory with the appropriate info. It will also update the policy database with the 
20 user's max bandwidth allowed. The SMM realizes it must allocate a co-located IP address for the MN. A request 

is made to DHCP to allocate the address. The SMM creates an address update request message with the MN co- 
located COA in it to send to the HMM. The message is forwarded to the local AAA server. 

i) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
lookup is performed to determine the I P address of the user's home AAA server and the type of security association 

25 (SA) established between the LSF and NSF. The local AAA server will then send the message to the user's home 

AAA server. Before the packet is sent, an IPSec authentication (AH) is performed on the message, 
j) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 
performs a lookup to see what server it should forward the message to. Since this is an address update request, 
iL forwards Ihe message Lo Lhe HMM. 

30 k) The HMM will perform the following functions: 

• Send a route update message to the local router so it can update the MN's IP address and MN co-located COA. 

• The HMM then creates an address update response message that includes the user's NAI, The HMM then 
sends the message to its home AAA server. 

35 

I) The AAA server will create an IPSec AH and send the message to the local AAA server serving the user, 
m) The local AAA server validates the IPSec AH and passes the message on to the SMM. 
n) The SMM will update its local directory with the appropriate info. The SMM may create an encryption key to be 
used by the user's MN. The SMM will send a registration reply to a mobility agent on the xAN/LSF router. 
40 o)The mobility agent at the xAN/LSF router must update the router's routing table to include the MN's IP address. 

The xAN must be told of the 'binding' between the MN's IP Address and the MN's L2 Address. The mobility agent 
then sends the registration reply to the MN. 

[0042] The flow in Fig. 6 describes an Initial Registration where the MN does not have an IP Address and where the 
45 MN and the user's home network are configured with non-routable IP addresses. The main difference between this 
flow and the flow associated with Fig. 4 is that the MN is not configured with an IP address. However, the home network 
is configured with routable IP addresses and will allocate a routable IP address to the MN. This flow also applies to 
the scenarios when the MN is initially powered on and when a user wants to connect to another service provider. 

so a) The user has powered on the MN (or initiated another service provider connection request). The MN is configured 

to send a registration message to the user's home network. The registration message is sent to the IP address 
(which is the IP address of the SMM) that was contained in the BCCH. The MS IP Address should beset to zero 
(0.0.0.0). 

b) The authentication procedure is performed. 
55 c) The SMM now needs to establish the packet data session with the user's home network. This is achieved by 

sending the home network a registration request. The following parameters are added to the registration message: 

• The LSF Info will contain information about the LSF and user mobility. 
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• The COA is the IP address that is used by the home network router and correspondent nodes to tunnel dat- 
agrams to the MN/LSF. There is an indication of the type of COA (not co-located). 

d) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
5 lookup is performed to determine the I P address of the user's home AAA server and the type of security association 

(SA) established between the LSF and NSF. The local AAA server will then send the message to the user's home 
AAA server. Before the packet is sent, an IPSec authentication (AH) is performed on the message. 

e) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 
performs a lookup to see what server it should forward the message to. Since this is a registration request, it 

10 forwards the message to the HMM. 

f) The HMM will perform the following functions: 

• Update the local directory with the LSF and mobility info. 

• Since the MN does not have a permanent IP address, the HMM will allocate an IP address via DHCP for the 
15 MN. The MN IP address is dynamically updated in the home network's DNS. 

• Send a route update message to the local router so it can update the MN's IP address and COA. 

• The HMM then creates a registration response message that includes the user's NAI, the user's profile, and 
the newly created MN IP address. The HMM then sends the registration response to its home AAA server. 

20 g) The AAA server will create an I PSec AH and send the message to the local AAA server serving the user. 

h) The local AAA server validates the I PSec AH and passes the message on to the SMM . 

i) The SMM will update its local directory with the appropriate info. It will also update the policy database with the 
user's max bandwidth allowed. The SMM realizes that the MN does not have an IP address. The SMM will send 
a registration reply to a mobility agent on the xAN/LSF router. The SMM will include the MN's layer 2 address in 

25 the reply. The xAN will use the layer 2 address to send the registration reply. 

j) The mobility agent at the xAN/LSF router must update the router's routing table to include the MN's IP address. 
The xAN must be told of the 'binding' between the MN's IP Address and the MN's L2 Address. The mobility agent 
'updates' the datagram's destination address to be a broadcast address sends the registration reply to the xAN 
sofLware and includes Ihe MN's L2 address so the xAN can route it to the MN. NOTE: If the xAN is an Ethernet 

30 access point, the broadcast message will be sent to all MNs on the link. 

[0043] The flow in Fig. 7 depicts an Initial Registration with hierarchical routers. The user is connecting to his/her 
home network where the home network is configured with routable IP addresses. The main difference between this 
flow and Fig. 4 is that there is a hierarchy of routers in the LSF/xAN. In particular, the xAN has a router at the edge of 
35 the xAN/LSF interface and there is another router, called the LSF router, which has a COA that is used to tunnel 
datagrams to. 

a) The user has powered on the MN (or initiated another service provider connection request). The MN is configured 
to send a registration message to the user's home network. The registration message is sent to the IP address 

40 (which is the IP address of the SMM) that was contained in the BCCH. 

b) The authentication procedure is performed. 

c) The registration procedure is performed. The COA sent in the registration message is the COA of the LSF router. 

d) The SMM will update its local directory with the appropriate info. The SMM will send a registration reply to a 
mobility agent on the xAN/LSF router. 

45 e) The mobility agent at the xAN/LSF router must update the router's routing table to include the MN's IP address. 

When this occurs, some routing protocol, e.g., RIP, will update the local network with routing information so data- 
grams can be delivered to the xAN router i.e., the LSF router will receive a route update and will know how to 
forward detunneled datagrams. The xAN must be told of the 'binding' between the MN's IP Address and the MN's 
L2 Address. The mobility agent then sends the registration reply to the MN. 

[0044] The discussion now turns to the scenario where users are roaming to new routing areas where there are no 
applications running (no data being transferred). When a user roams between LSFs, the user changes subnet points- 
of-attachments (it changes routing areas - RAs). The LSF needs to know about the RA changes for the following 
reasons: the LSF may want to re-authenticate the user to avoid fraudulent users (in an IP centric network, it is advisable 
55 to always have the LSF authenticate the user); the user may have access restrictions within this RA; and a different 
IP router may need to provide tunneling services, via a new COA, to the MN while it is in the new RA. 
[0045] In the architecture of the present invention, before the MN moves to the new LSF, it will send a registration 
request message to old LSF that indicates the MN is about to move to the new LSF. This triggers the old LSF to start 
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queuing MN datagrams. 

[0046] When the registration process is invoked, it may be necessary to perform registration for multiple users, all 
of whom may be registered with their respective ISPs. There are several alternatives for this scenario: 

5 • Have the MN send a registration message for each NAI that is in an active packet data session. 

• Have the MN send a single registration message that includes all the NAIs and their associated parameters. This 
could end up being a very large message sent over the air. It would be prone to transmission errors, hence re- 
transmissions of the long message. 

• Have the MN send a single registration message for only one of the NAIs e.g. the one associated with the first 
10 active data session. If the LSF has a policy to authenticate users, the LSF will request authentication for the single 

NAI. This may be a little risky since the authentication mechanism may be weak authentication, e.g., login ID and 
password, which is more prone to fraud (this is subjectto the architecture supporting legacy authentication mech- 
anisms). 

15 Have the MN send a single registration message that does not include any NAIs. The LSF could have a policy that 
initiates a unique challenge for each NAI associated with the MN (NAIs should be associated with the MN's L2 Address). 
[0047] The flow in Fig. 8 depicts a MN moving to a new routing area in a new LSF: 

a) The MN detects it will move to a new system (new LSF). The MN informs the current system (old xAN/LSF) 
20 about to move by sending a registration message to the 'old' system (LSF) with a registration type of 'Prepare for 

System Change'. The 'old' system will have its router (xAN) start queuing datagrams for the MN. The user may be 
authenticated before buffering begins. The parameters in brackets are optional. 

b) The authentication procedure is performed. If the MN and the LSF have established keys to be used for over 
the air encryption, it may not be necessary to authenticate the user. 

2s c) The SMM informs the mobility agent on the old router to start buffering datagrams destined to the user's MN. 

d) The router mobility agent acknowledges the message. 

e) The SMM acknowledges the registration request, 

f) The MN has determined it has crossed over a LSF boundary (via a new system ID). The MN sends a registration 
message Lo Lhe IP address (which is the IP address of the SMM) that is contained in the BCCH. The MN will send 

so a registration request message for each active packet data session it has. In this scenario, there is only one active 

packet data session. The message includes the old LSF's system ID. 

g) The SMM detects that the registration type is 'System Change' and that the message includes the Old LSF ID. 
The SMM needs to request MN information from the old LSF and have the old LSF start buffering datagrams 
destined to the MN. This is achieved by sending the old LSF a context request message via the local AAA server. 

35 The SMM will put the old LSF's NAI in the message so the local AAA server can route the message (to simplify 

this, the SMM may pass the IP address of the old LSF). 

[0048] If there is more than one active packet data session for the MN, the MN will send a registration request 
message for each active packet data session it has. This will incur multiple context requests being issued by the new 
40 LSF. (We can optimized this by sending a single context request that includes the MN's L2 Addr to the old LSF.) The 
context response will include MN information for all active packet data sessions. Hence, the new LSF will not have to 
send a context request message for each registration message. 

[0049] The local AAA server uses the domain portion of the old LSF's NAI to determine the LSF's system. A lookup 
is performed to determine the IP address of LSF's AAA server and the type of security association (SA) established 
45 between the LSF and LSF. The local AAA server will then send the message to the LSF's AAA server. Before the 
packet is sent, an IPSec authentication (AH) is performed on the message. 

h) TheOld LSF's AAA server receives the message. TheAAAserverwillfirstvalidate the IPSec AH. Itthen performs 
a lookup to see what server it should forward the message to. Since this is a context request, it forwards the 

so message to the SMM. 

i) The SMM informs the mobility agent on the old router to start buffering datagrams destined to the user's MN. 
NOTE: The buffer data request can have multiple MN IP addresses. Also, if the SMM had previously initiated a 
buffer request (during the System Change Procedure), the SMM does not have to reissue the request here. 
j)The router mobility agent updates the local router to start queuing datagrams destined to the MN and then sends 

55 an acknowledge message back to the SMM. 

k) The SMM creates a context response message with the MN's IP address(es) and sends it back to the new LSF 
SMM. All the normal AAA server functions are also executed. Additionally, it is not necessary to send the user's 
profile since this will be retrieved during the registration procedure. 
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I) The authentication procedure is performed. 

m) The registration procedure is performed. The functions of the registration procedure performed here will be 
slightly different from the functions performed at the initial registration. As an example, there will be no processing 
performed due to the profile type. 

5 n) The registration reply procedure is performed. 

o) The new LSF's SMM creates a Binding Update request message that includes the user's NAI and the COA of 
the router that the MN's datagrams need to be tunnel to and sends it to the old LSF's SMM. (Note: all the normal 
AAA server functions get executed.) This request will allow the old LSF to start forwarding the MN's datagrams, 
p) The old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN router to request 

10 that the router start forwarding datagrams to the new router's COA. 

q) The mobility agent acknowledges the forward packets request. 

r) The SMM creates a Binding Update response message with the user's NAI and sends it to the new LSF's SMM. 
(Note: all the normal AAA server functions get executed.) 

s) After the user's home NSF performed the registration, it must send the old LSF a registration cancellation mes- 
15 sage. (Note: all the normal AAA server functions get executed.) The reason for sending the registration cancellation 

is that there is a window where the home NSF may have sent a CN a binding update that had the old LSF's COA. 
The home NSF must now update the CN with the new COA and then perform the registration cancellation proce- 
dure. This will insure that the old LSF will not stop forwarding datagrams to the MN prematurely. NOTE: The 
registration procedure is being performed in parallel to the Binding Update procedure (which was initiated by the 
20 new LSF in step 'n'). Also, it is not necessary for the NSF to have a retry counter associated with the registration 

cancellation request. 

t) The old LSF's SMM initiates the cleanup. The cleanup will only be performed after both the Binding Update has 
completed and the registration cancellation is completed, 
u) The router's mobility agent acks the message. 
25 v) The old LSF acks the registration cancellation request. (Note: all the normal AAA server functions get executed. 

[0050] The flow in Fig. 9 represents the MN moving to a new routing area (RA), where the user is roaming between 
xANs within the same LSF. The registration request message sent through the old xAN indicates movement to another 
system (xAN) and triggers Ihe LSF to start queuing MN datagrams at the old xAN. 

30 

a) The System Change procedure is performed. 

b) MN has determined it has crossed over a xAN boundary (via a new system ID). The MN sends a registration 
message to the IP address (which is the IP address of the SMM) that is contained in the BCCH or Agent Adver- 
tisement. The MN will send a registration request message for each active packet data session it has. In this 

35 scenario, there is only one active packet data session. The message includes the old LSF's system ID. 

c) The Authentication procedure is performed. 

d) The Address Update procedure is performed. 

e) The Registration Reply procedure is performed. 

f) The LSF's SMM sends a Forward Packets message to the mobility agent on the old xAN router to request that 
40 the router start forwarding datagrams to the new router's COA. These datagrams will be tunneled to the new 

router's COA. 

g) The mobility agent informs the xAN/router to start forwarding packets and acknowledges the Forward Data 
request. 

h) The Registration Cancellation procedure is performed. 

45 

[0051] The flow in Fig. 1 0 represents a user roaming between RAs within the same xAN/LSF. However, at the xAN/ 
LSF boundary there are multiple routers and thus, multiple routing areas (each having their own COA). When the user 
roams in a new RA, the associated COA must be updated at the user's home network. 

[0052] There is an alternative to assigning a new COA for the user/MN. Instead of allocating a new COA and updating 
so the COA at the user's home network, the original router could bean anchor point. In such a scenario, the original router 
(s) would be updated with information on how to route MN datagrams to the new router(s). This discussion, however, 
will be limited to updating COAs. 

a) The System Change procedure is performed. 
55 b) The MN has determined it has crossed over a routing area boundary. The MN will send a registration message 

for each active packet data session it has. In this scenario, there is only one active packet data session. 

c) The authentication procedure is performed. 

d) The SMM informs the mobility agent on the old router to start buffering datagrams destined to the user's MN. 
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The SMM will not issue the buffer data request if it was performed during the system change procedure. 

e) The router mobility agent acknowledges the message. 

f) The Address Update Procedure is performed. 

g) The registration reply procedure is performed. 

5 h) The SMM informs the mobility agent on the old router to start forwarding datagrams destined to the user's MN. 

These datagrams will be tunneled to the new router's COA. 
i) The router mobility agent acknowledges the message. 

j) The SMM informs the mobility agent on the old router to have the xAN clean up its resources, 
k) The router mobility agent acknowledges the message. 

[0053] The flow in Fig. 11 represents a user roaming to a new routing area where the MN's COA does not change. 
It should be noted that the MN does not know that the COA will not change. However, during the system change 
procedure, the SMM will know and will not have to buffer datagrams destined to the MN. 

15 a) The System Change procedure is performed. 

b) The MN has determined it has moved to a new routing area. The MN will send a registration message for each 
active packet data session it has. In this scenario, there is only one active packet data session. 

c) The authentication procedure is performed. 

d) If the user was authenticated, the SMM will update its local directory with the new RA and send a registration 
20 reply to the MN. Since a new COA was not allocated for the user, there are no other functions that the SMM needs 

to perform. 



[0054] The flow in Fig. 12 represents a user roaming back into their home network, where the network is a combined 
LSF/NSF. The home subnet is accessed over the RAN, not over an Ethernet connection. The combined LSF/NSF may 
25 be on the same subnet. 



a) The System Update procedure is performed. 

b) MN has determined it has crossed over a LSF boundary (via a new system ID). The MN sends a registration 
message Lo Lhe IP address (which is the IP address of the SMM) thai is contained in the BCCH. The MN will send 

so a registration request message for each active packet data session it has. In this scenario, there is only one active 

packet data session. The message includes the old LSF's system ID. 

c) The context request procedure is performed. 

d) The SMM creates an AAA Authentication Request and forwards it to the LSF's local AAA server, NOTE: If the 
SMM and the Authentication center are on the same subnet (or even on the same server) it is not necessary to 

35 have the Authentication Request go through the AAA server. 

e) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
lookup is performed to determine the IP address of the user's home AAA server and the type of security association 
(SA) established between the LSF and NSF. The AAA server realizes it is its own network, so it forwards the 
message directly to the Authentication Server. 

40 f) The authentication server authenticates the user. The authentication server then sends an authentication re- 

sponse to its home AAA server. 

g) The AAA server realizes it is its own network, so it forwards the message directly to the SMM. 

h) The SMM creates a registration request message and forwards it to the LSF's local AAA server. NOTE: If the 
SMM and the HMM are on the same subnet (or even on the same server) it is not necessary to have the Authen- 

45 tication Request go through a AAA server 

i) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
lookup is performed to determine the I P address of the user's home AAA server and the type of security association 
(SA) established between the LSF and NSF. The AAA server realizes it is its own network, so it forwards the 
message directly to the Authentication Server. 

so j) The HMM will perform the following functions: 



• Update the local directory with the LSF and mobility info. 

• Send a route update message to the local router so it can update the MN's IP address. 

• The HMM then creates a registration response message that includes the user's NAI and sends the registration 
response to its AAA server. 

k) The AAA server realizes it is its own network, so it forwards the message directly to the SMM. 
I) The Registration Reply procedure is performed. 
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m) The Binding Update procedure is performed. 

n) The Registration Cancellation procedure is performed. 

[0055] The flow in Fig. 13 represents a user roaming between LSFs where the MN does not send a registration 
5 request message to the old LSF that indicates the MN is about to move. This is the main difference between this flow 
and the flow in Fig. 8. During the MN's transition to the new LSF, there is a window where the old LSF may lose 
datagrams destined to the MN while the MN was accessing the new LSF. This flow helps to minimize this window by 
having the new LSF request the old LSF to start queuing datagrams for the MN. It is questionable on how large of a 
window there is for loss of data since the old LSF may be in the process of paging the MN. and hence already queuing 
10 the datagrams. 

a) The MN has determined it has crossed over a LSF boundary (via a new system ID). The MN will send a regis- 
tration message for each active packet data session it has. In this scenario, there is only one active packet data 
session, registration message includes the old LSF's system ID. 
15 b) The Context Request procedure is performed. 

c) The Authentication procedure is performed. 

d) The Registration procedure is performed. 

e) The Registration Reply procedure is performed. 

f) The Binding Update procedure is performed. 

20 g) The Registration Cancellation procedure is performed. 

[0056] The flow in Fig. 1 4 represents a user terminating a connection to their service provider: 

a) The user wants to disconnect (log off) from their service provider. Via some interface or configured button, the 
25 user selects the provider they want to disconnect from. The MN sends the de-registration message with the Reg- 
Type field set to de-registration. 

b) The authentication procedure is performed. 

c) The SMM sends a registration request to the local AAA server. 

d) The local AAA server uses the domain portion of the user's NAI to determine the home system of the user. A 
30 lookup is performed to determine the I P address of the user's home AAA server and the type of security association 

(SA) established between the LSF and NSF. The local AAA server will then send the message to the user's home 
AAA server. Before the packet is sent, an IPSec authentication (AH) is performed on the message. 

e) The user's home AAA server receives the message. The AAA server will first validate the IPSec AH. It then 
performs a lookup to see what server it should forward the message to. It forwards the message to the HMM. 

35 f) The HMM will perform the following functions: 

• Send a route update message to the local router so it can remove the MN's IP address and COA from the 
routing table. 

• Update its local directory. 

40 . Update the user's entry in DNS. 

• If the MN's IP address was allocate via DHCP, the HMM will give it back. 

• The HMM then creates a deactivate response message that includes the user's NAI and sends it to its home 
AAA server. 

45 g) The AAA server will create an IPSec AH and send the message to the local AAA server serving the user. 

h) The local AAA server validates the I PSec AH and passes the message on to the SMM . 

i) The SMM will cleanup and send the registration reply to the mobility agent at the xAN/LSF router. 

j) The mobility agent will remove the MN's IP address from the router's route table and forward the registration 
reply to the MN. 

[0057] The discussion now turns to the scenario where users roam to new routing areas where there are applications 
running (handoffs). 

[0058] The flow in Fig. 15 represents a handoff between two LSFs. In this flow, the old LSF recieves a handoff 
indication from the xAN. The reason for this is that there are windows where the MN's registration request, with RegType 
55 set to 'Prepare for System Change', may not get to the old LSF's SMM. To insure that the MN's datagrams are queued, 
the xAN must send the handoff required message. 

[0059] During handoff, it is a goal to not lose any data. To achieve this goal, datagrams destined to the MN are 
buffered as early as possible. The scenario for when XolP datagrams (where X may be voice, data, multi-media, etc.) 
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arrive at the xAN has three alternatives: have the xAN buffer the XolP datagrams; have the xAN discard (drop) the 
XolP datagrams; and forward the XolP datagrams to the newxAN/LSF. The current handoff message flows buffer the 
XolP datagrams. It is important to note that the handoff procedure, which triggers the allocation of xAN resources in 
the new LSF, does not have to be performed by the LSF. We can make this procedure be controlled by the xANs. 

5 

a) The System Update procedure is performed. 

b) The xAN (actually the mobility agent on the xAN router) sends the SMM a handoff required message which 
indicates the target LSF for the handoff. 

c) The SMM forwards the handoff required message to the new LSF SMM. (Note: all the normal AAA server 
10 functions get executed.) The Call Info field includes all the current active data session for this MN (there is only 

one for this scenario). The LSF domain is sent so the SMM in the new LSF knows were the request came from. 
The LSF domain can be used by the new LSF's SMM for routing. The LSF does not have to be involved with the 
actual handoff. The Handoff Procedure can be performed by the xANs themselves. If the xANs do perform the 
procedure, they are responsible for queuing the MN's datagrams 
15 d) The handoff required message indicates the target for the handoff. The SMM sends an activate packet service 

request to the xAN so it can allocate the appropriate resources. An activate packet service request is sent for every 
active session that is listed in the Call Info field. 

e) The xAN allocates the appropriate resources and sends an activate packet service response back to the SMM. 

f) The new SMM sends a handoff required acknowledge to the old SMM and all the normal AAA server functions 
20 get executed. 

g) The SMM sends a Handoff required acknowledge message to the mobility agent on the xAN router. This inform 
the xAN that the handoff is set up. If we have not started queuing datagrams for the MN, it should start queuing 
now, i.e., the handoff required acknowledge doubles as a buffer data request. 

h) The MN returns to the appropriate frequency. The MN realizes it has crossed over a LSF boundary (via a new 
25 system ID). Italso realizesthatthereareactive application sessions, hence itwill setthe RegTypeto be'SystemHO'. 

The MN will send a registration request message for each active packet data session it has. In this scenario, there 
is only one active packet data session. The message includes the old LSF's system ID. 

i) The Context Request procedure is performed. If the LSF is responsible for performing the Handoff Procedure, 
this step does not have to be performed. 

30 j) The Authentication procedure is performed. Authentication does not have to be performed at this step, We can 

complete the handoff then perform a unique challenge to authenticate the user, 
k) The Registration procedure is performed. 

I) The RegislraLion Reply procedure is performed. The Binding Update procedure is performed, 
m) The MN realizes that it is in a new system and has active application sessions, hence, it send the SMM a list 
35 of correspondent nodes it is in communications with. Note: An alternative to this would be to have the home network 

request the CN list from the MN after the home network was updated with the new COA. 
n) The SMM forwards the message to the HMM at the MN's NSF and all the normal AAA server functions get 
executed. 

o) The HMM acknowledges the correspondent node list and all the normal AAA server functions get executed. 
40 p) The SMM forwards the message to the MN. 

q) When the HMM has received a Correspondent Node (CN) 38 list, it will send binding updates that include the 

MN's new COA to the CNs. 

r) The CNs will acknowledge the binding update. 

s) The Registration Cancellation procedure is performed, 

45 

[0060] The flow in Fig. 1 6 represents a handoff between two xANs on the same LSF. 

a) The System Update procedure is performed. 

b) The xAN (actually the mobility agent on the xAN router) sends the SMM a handoff required message which 
so indicates the target LSF for the handoff. 

c) The Handoff procedure is performed. 

d) The SMM sends a Handoff required acknowledge message to the mobility agent on the xAN router. This informs 
the xAN that the handoff is set up. If the datagrams have not started queuing for the MN, they should start queuing 
(the handoff required acknowledge doubles as a buffer data request). 

55 e) The MN returns to the appropriate frequency. The MN realizes it has crossed over a LSF boundary (via a new 

system ID). Italso realizesthatthereareactive application sessions, hence itwill setthe RegTypeto be'SystemHO'. 
The MN will send a registration request message for each active packet data session it has. In this scenario, there 
is only one active packet data session. The message includes the old LSF's system ID. 
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f) The Authentication procedure is performed. 

g) The Registration procedure is performed. 

h) The Registration Reply procedure is performed. 

i) The old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN router to request 
5 that the router start forwarding datagrams to the new router's COA. These datagrams will be tunneled to the new 

router's COA. 

j) The mobility agent informs the xAN/routerto start forwarding packets. 

k) The MN realizes that it is in a new system and has active application sessions, hence, it sends its home network 
a list of correspondent nodes it is in communications with. Note: An alternative to this would be to have the home 
10 network request the CN list from the MN after the home network was updated with the new COA. 

I) The HMM acknowledges the correspondent node list. 

m) When the HMM has received both the CN list and the new COA, it will send binding updates that include the 
new COA to the CNs. 
n) The CNs will ack the binding update 
15 o) The Registration Cancellation procedure is performed. 

[0061] The flow in Fig. 1 7 depicts a handoff between two xANs on the same LSF. The main difference between this 
flow and the flow in Fig. 16 is that there is a hierarchy of routers in the LSF/xAN. 

20 a) The System Update procedure is performed. 

b) The xAN (actually the mobility agent on the xAN router) sends the SMM a handoff required message which 
indicates the target LSF for the handoff. 

c) The Handoff procedure is performed. 

d) The SMM sends a Handoff required acknowledge message to the mobility agent on thexAN router. This informs 
2s the xAN that the handoff is set up. If we have not started queuing datagrams for the MN, it should start queuing 

now, i.e., the handoff requided acknowledge doubles as a buffer data request. 

e) The MN retunes to the appropriate frequency. The MN realizes it has crossed over a LSF boundary (via a new 
system ID). It also realizes that there areactive application sessions, hence itwill setthe RegTypeto be'SystemHO 1 . 
The MN will send a registration request message for each active packet data session it has. In this scenario, there 

30 is only one active packet data session. The message includes the old LSF's system ID, 

f) The Authentication procedure is performed. 

g) The Registration procedure is performed. 

h) The SMM will update its local directory with the appropriate info. The SMM will send a registration reply to a 
mobility agent on the xAN/LSF router, 

35 i) The mobility agent at the xAN/LSF router must update the router's routing table to include the MN's IP address. 

When this occurs, some routing protocol, e.g., RIP, will update the local network with routing information so data- 
grams can be delivered to the xAN router, i.e., the LSF router will receive a route update and will know how to 
forward detunneled datagrams. The xAN must be told of the 'binding' between the MN's IP Address and the MN's 
L2 Address. The mobility agent then sends the registration reply to the MN. 

40 j) The old LSF's SMM sends a Forward Packets message to the mobility agent on the LSF/xAN router to request 

that the router start forwarding datagrams to the new router's COA. These datagrams will be tunneled to the new 
router's COA. 

k) The mobility agent informs the xAN/routerto start forwarding packets. 
I) The Update CN procedure is performed. 
45 m) The Registration Cancellation procedure is performed. 

[0062] Fig. 1 8 depicts a computer 40 (which contains a computer program) that comprises a processor 42 and mem- 
ory 44. The computer 40 may be a personal computer or laptop, a LSF 14, a NSF 16, a service broker 18, a xAN 20, 
a MN 22, a SMM 26, a HMM 28, a AAA server 30, a security gateway 32, a router 34, an authentication server 36, a 

so correspondent node 38 and/or any device that can send and receive IP mobility extension messages. The processor 
42 may be a central processing unit, digital signal processor, microprocessor, microcontroller, microcomputer, and/or 
any device that manipulates digital information based on programming instructions. The memory 44 may be read-only 
memory, random access memory, flash memory and/or any device that stores digital information. The memory 44 is 
coupled to the processor 42 and stores programming instructions that, when read by the processor, cause the processor 

55 to perform certain processing operations. 

[0063] Fig. 1 9 describes a method for utilizing IP mobility messages and AAA messages in a communication system 
that may be implemented by the computer 40 of Fig. 1 8. The communication system comprises a data network coupled 
to a visited network, a home network, and a service broker, wherein the visited network and the home network are 
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each coupled to an access node. The method begins at decision 50 where a serving mobility manager (SMM) receives 
via the access node, a user request for information, where the SMM is located in the visited network. At step 52 a local 
AAA server queries the service broker to determine the user's home network, where the local AAA server is coupled 
to the SMM and located in the visited network, and where the service broker is coupled to the visited network and the 

5 home network. The method proceeds to step 54 where a service broker AAA server contacts a home AAA server, 
where the home AAA server is located in the home network, and where the service broker AAA server is located in 
the service broker. At step 56, the service broker AAA server establishes a trust relationship between the visited network 
and the home network by utilizing an extension of the IP mobility messages, where the IP mobility extension messages 
are combined with the AAA messages to provide mobility functionality to the AAA messages. At step 58, a home 

10 mobility manager (HMM) transmits to the user, the information via the data network, the SMM, and the access node 
using the trust relationship, where the HMM is coupled to the home AAA server and is located in the home network. 
[0064] The present invention thus enjoys several advantages. For example, the IP mobility extension messages are 
combined with the AAA messages to provide mobility functionality to the AAA messages. These IP mobility extension 
messages now provide an IP centric network with a mobility protocol that can be used to communicate between the 

15 various entities in the IP network. Further, these IP networks may be utilized via a plurality of access protocols. 

[0065] It is understood that variations may be made in the foregoing without departing from the scope of the present 
invention. For example, any number and combination of entities such as a LSF 14. a NSF 16, a service broker 18, a 
xAN 20, a MN 22, a SMM 26, a HMM 28, a AAA server 30, a security gateway 32, a router 34, an authentication server 
36, a correspondent node 38, and a computer 40 may be used with the present network 10. Further, the system 10 

20 may be connected to another wireless, wireline, data, voice, and/or multi-media system. Also, the computer program 
(s) that facilitate the IP mobility extension messaging may be fully and/or partially contained in the entities described 
above. 

[0066] It is further understood that other modifications, changes and substitutions are intended in the foregoing dis- 
closure and in some instances some features of the disclosure will be employed without corresponding use of other 
25 features. Additionally, singular discussion of items located in the network 1 0 is also meant to apply to situations where 
multiple items exist. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner 
consistent with the scope of the disclosure. 



A method for utilizing Internet Protocol (IP) mobility messages and Authentication, Authorization, and Accounting 
(AAA) messages in a communication system comprising a data network coupled to a visited network, a home 
network, and a service broker, wherein the visited network and the home network are each coupled to an access 
node, the method comprising: 

receiving, by the visited network via the access node, a user request for information; 

querying, by the visited network, the service brokerto determine the user's home network, wherein the service 

broker is coupled to the visited network and the home network; 

contacting, by the service broker, the home network; 

establishing, by the service broker, a trust relationship between the visited network and the home network by 
utilizing an extension of the IP mobility messages, wherein extensions to the IP mobility messages are com- 
bined with the AAA messages to provide mobility functionality to the AAA messages; and 
transmitting, by the home network to the user, the information via the data network, the visited network, and 
the access node using the trust relationship. 

A method according to claim 1 , in which a serving mobility manager (SMM) is located in the visited network, a local 
AAA server is coupled to the SMM and located in the visited network, a service broker AAA server is located in 
the service broker, a home AAA server is located in the home network, and a home mobility manager (HMM) is 
coupled to the home AAA server and is located in the home network, wherein the step of receiving the user request 
includes the step of the SMM receiving via the access node the user request for information, the step of querying 
includes the step of the local AAA server querying the service brokerto determine the user's home network, the 
step of contacting includes the step of the service broker AAA server contacting the home AAA server, and the 
step of transmitting includes the step of the home mobility manager (HMM) transmitting to the user, the information 
via the data network, the SMM, and the access node using the trust relationship. 

A method according to claim 1 or 2, further comprising the step of transmitting the user request via a plurality of 
access protocols. 
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4. A method according to claim 1 , 2 or 3, wherein the IP mobility extension messages comprise base AAA headers, 
message specific attribute value pairs, and message specific parameters. 

5. A method according to claim 1,2,3 or 4, further comprising the step of creating the IP mobility extension messages 
intheSMM. 

6. A method according to claim 1 , 2. 3 or 4, further comprising the step of creating the IP mobility extension messages 
in the HMM. 

7. A method according to any preceding claim, wherein the IP mobility extension messages comprise registration 
messages, wherein the registration messages comprise: 

a registration request message; 

a registration response message; 

a registration cancellation message; 

a registration cancellation acknowledge message; 

an address update request message; 

an address update response message; 

a terminate call request message; and 

a terminate call response message. 

8. A method according to any of claims 1 to 6, wherein the IP mobility extension messages comprise inter-local 
serving function messages, wherein the inter-local serving function messages comprise: 

a context request message; 

a context response message; 

a binding update request message; and 

a binding update response message. 

9. A method according to any of claims 1 to 6, wherein the IP mobility extension messages comprise proxy/broker 
messages, wherein the proxy/broker messages comprise: 

a discover request message; and 
a discover response message. 

10. A method according to any of claims 1 to 6, wherein the IP mobility extension messages comprise correspondent 
messages, wherein the correspondent messages comprise: 

a correspondent node list message; and 

a correspondent node list acknowledge message. 

1 1 . A method according to claim 7, wherein the registration request message comprises at least one of the following 
message specific parameters from the group consisting of 

a user NAI; 

an IP address of a mobile node; 

local serving function NAI; 

a care of address of the mobile node; 

a profile type; 

a terminal type; 

a service level request; 

a signal strength; 

a protocol version; 

a destination NAI; 

a source NAI; and 

a time stamp. 

1 2. A method according to claim 7, wherein the registration response message comprises at least one of the following 
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message specific parameters from the group consisting of 

a user NAI; 

an IP address; 
5 a profile; 

a care of address required; 

a response code; 

an authorization period; 

a destination NAI; 
10 a source NAI; and 

a time stamp. 

13. A method according to claim 7, wherein the registration cancellation message comprises at least one of the fol- 
lowing message specific parameters from the group consisting of: 

a user NAI; 

a local serving function NAI; 
a Level 2 address; 
a mobile station IP address; and 
20 aHMMNAI. 

14. A method according to claim 7, wherein the registration cancellation acknowledge message comprises at least 
one of the following message specific parameters from the group consisting of: 

25 a user NAI; 

a destination NAI; 
a source NAI; and 
a time stamp. 

30 1 5. A method according to claim 7, wherein the address update request message comprises at least one of the following 
message specific parameters from the group consisting of: 

a user NAI; 

a co-located care of address; 
35 a MS IP Address; 

a destination NAI; 
a source NAI; and 
a time stamp. 

40 16. A method according to claim 7, wherein the address update response message comprises at least one of the 
following message specific parameters from the group consisting of: 

a user NAI; 
a MS IP Address; 
45 a destination NAI; 

a source NAI; and 
a time stamp. 

17. A method according to claim 8, wherein the context request message comprises at least one of the following 
so message specific parameters from the group consisting of: 

a user NAI; 

a previous local serving function NAI; 
a Level 2 address; 
55 a context request type; 

a destination NAI; 
a source NAI; and 
a time stamp. 
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18. A method according to claim 8, wherein the context response message comprises at least one of the following 
message specific parameters from the group consisting of: 

a user NAI; 

a current local serving function NAI; 

a mobile station IP address; 

a response code; 

a context date; 

a destination NAI; 

a source NAI; and 

a time stamp. 

1 9. A method according to claim 8, wherein the binding update request message comprises at least one of the following 
message specific parameters from the group consisting of: 

a user NAI; 

a local serving function NAI; 
a mobile station IP address; 
a destination NAI; 
a source NAI; and 
a time stamp. 

20. A method according to claim 8, wherein the binding update response message comprises at least one of the 
following message specific parameters from the group consisting of: 

a user NAI; 
a response code; 
a destination NAI; 
a source NAI; and 
a time stamp. 

21. A method according to claim 9, wherein the discover request message comprises at least one of the following 
message specific parameLers from the group consisting of: 

a user NAI; 
a destination NAI; 
a source NAI; and 
a time stamp. 

22. A method according to claim 9, wherein the discover response message comprises at least one of the following 
message specific parameters from the group consisting of: 

a user NAI; 
an HA address; 
a destination NAI; 
a source NAI; and 
a time stamp. 

23. A method according to claim 10 ; wherein the correspondent node list message comprises at least one of the 
following message specific parameters from the group consisting of: 

a user NAI; and 

a correspondent node IP list; 

a destination NAI; 

a source NAI; and 

a time stamp. 

24. A method according to claim 10, wherein the correspondent node list acknowledge message comprises at least 
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one of the following message specific parameters from the group consisting of: 

a user NAI; 
a response code; 
5 a destination NAI; 

a source NAI; and 
a time stamp. 

25. A method according to any preceding claim, further comprising the step of pre-configuring a trust relationship 
10 between the visited network and user's home network, wherein the steps of querying and contacting comprises 

the step of querying, by the visited network, the user's home network, via the pre-configured trust relationship. 

26. A method according to any of claims 1 to 24, wherein the steps of querying, contacting and establishing are per- 
formed dynamically to establish a relationship with the home network. 

27. A computer program comprising computer program code means for performing the steps of any one of claims 1 
to 26 when said program is run on a computer or a number of computers. 

28. A computer program as claimed in claim 27 embodied on a computer readable medium. 

20 

29. A system for utilizing Internet Protocol (IP) mobility messages and Authentication, Authorization, and Accounting 
(AAA) messages, the system comprising a data network coupled to a visited network, a home network, and a 
service broker, wherein the visited network and the home network are each coupled to an access node, and wherein 
the system further comprises: 

25 

means for receiving, by the visited network via the access node, a user request for information; 
means for querying, by the visited network, the service broker to determine the user's home network, wherein 
the service broker is coupled to the visited network and the home network; 
means for contacting, by Ihe service broker, the home network; 
30 means for establishing, by the service broker, a trust relationship between the visited network and the home 

network by utilizing an extension of the IP mobility messages, wherein the IP mobility extension messages 
are combined with the AAA messages to provide mobility functionality to the AAA messages; and 
means for transmitting, by the home network to the user, the information via the data network, the visited 
network, and the access node using the trust relationship. 

35 

30. A system according to claim 29, the means for receiving including a serving mobility manager (SMM) located in 
the visited network, the means for querying including a local AAA server coupled to the SMM and located in the 
visited network, the means for contacting and means for establishing including a service broker AAA server located 
in the service broker and a home AAA server located in the home network, and the means for transmitting including 

40 a home mobility manager (HMM) located in the home network. 

31 . A system according to claim 29 or 30 further comprises means for transmitting the user request via a plurality of 
access protocols. 

45 32. A system according to claim 29, 30 or31 , wherein the IP mobility extension messages comprise base AAA headers, 
message specific attribute value pairs, and message specific parameters. 

33. A system according to any of claims 29 to 32, further comprising means for creating the IP mobility extension 
messages in the visited network. 

34. A system according to any of claims 29 to 32, further comprising means for creating the IP mobility extension 
messages in the home network. 

35. A system according to any of claims 29 to 34, wherein the IP mobility extension messages comprise registration 
55 messages, wherein the registration messages comprise: 

a registration request message: 
a registration response message; 
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a registration cancellation message; 
a registration cancellation message; 
an address update request message; 
an address update response message; 
5 a terminate call request message; and 

a terminate call response message. 

36. A system according to any of claims 29 to 34, wherein the IP mobility extension messages comprise inter-local 
serving function messages, wherein the inter-local serving function messages comprise: 

10 

a context request message; 

a context response message; 

a binding update request message; and 

a binding update response message. 

37. A system according to any of claims 29 to 34, wherein the IP mobility extension messages comprise correspondent 
messages, wherein the correspondent messages comprise: 

a correspondent node list message; and 
20 a correspondent node list acknowledge message. 

38. A system according to any of claims 29 to 37, in which a pre-configured trust relationship is established between 
the visited network and the user's home network, wherein the pre-configured trust relationship is used in place of 
the means for contacting and establishing. 

25 

39. A system comprising means for combining an extension of IP mobility messages with AAA messages to provide 
mobility functionality to the AAA messages. 

40. A system comprising means for utilizing an extension of IP mobility messages with AAA messages to provide 
30 mobility functionality to the AAA messages in the system. 

41. A system comprising: 

means for registering a user; 

35 means for permitting, by the system, the user to roam to new routing areas where there are no applications 

running; and 

means for permitting, by the system, the user to roam to new routing areas where there are applications 
running, wherein the user's mobile node utilizes a combination of an extension of IP mobility messages with 
AAA messages to access the applications. 

42. A system for roaming between routing areas within the same Access Node/Local Serving Function (xAN/LSF), the 
system utilizing Internet Protocol (IP) mobility messages and Authentication, Authorization, and Accounting (AAA) 
messages and comprising a data network coupled to a visited network, a home network, and a service broker, 
wherein the visited network and the home network are each coupled to an access node, and wherein the system 

45 further comprises: 

means for performing, by the system, a system change; 

means for sending, by a mobile node, a registration message for each active packet data session, wherein 

the mobile node transmits and receives datagrams between the system; 
so means for performing, by the system, authentication; 

means for buffering the datagrams, by the xAN, destined to the user's mobile node; 

means for acknowledging, by a serving mobility manager (SMM), a datagram buffering message; 

means for performing, by the system, an address update procedure; 

means for performing, by the system, a registration reply procedure; 
55 means for forwarding, by the xAN, datagrams destined to the user's mobile node; 

means for acknowledging, by the SMM, a datagram forwarding message; 

means for requesting, by the SMM, a clean up of the xANs resources; and 

means for acknowledging, by the SMM, the clean up message. 



33 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




35 



4/16/2008, EAST Version: 2.2.1.0 



EP 1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




38 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




40 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 




45 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




47 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 




49 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




50 



4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 




4/16/2008, EAST Version: 2.2.1.0 



EP1 111 872 A2 



FIG. 18 



FIG. 19 



( START ) 



RECEIVING, BY A SERVING MOBILITY MANAGER 
(SUM) VIA THE ACCESS NODE, A USER REQUEST 
FOR INFORMATION, WHEREIN THE SMM IS 
LOCATED IN THE VISITED NETWORK 



QUERYING, 8Y A LOCAL AAA SERVER, THE SERVICE 
BROKER TO DETERMINE THE USER'S HOME 
NETWORK, WHEREIN THE LOCAL AAA SERVER IS 
COUPLED TO THE SMM AND LOCATED IN THE 
VISITED NETWORK, AND WHEREIN THE SERVICE 
BROKER IS COUPLED TO THE VISITED NETWORK 
AND THE HOME NETWORK 



CONTACTING, BY A SERVICE BROKER AAA SERVER, 
A HOME AAA SERVER, WHEREIN THE HOME AAA 
SERVER IS LOCATED IN THE HOME NETWORK, 

AN'O WHEREIN THE SERVICE 8R0KER AAA 
SERVER IS LOCATED IN THE SERVICE BROKER 



ESTABLISHING. BY THE SERVICE BROKER AAA 
SERVER, A TRUST RELATIONSHIP BETWEEN THE 
VISITED NETWORK AND THE HOME NETWORK BY 
UTILIZING AN EXTENSION OF THE IP MOBILITY 

MESSAGES, WHEREIN THE IP MOBILITY 
EXTENSION MESSAGES ARE COMBINED WITH THE 
AAA MESSAGES ^0 PROVIDE MOBILITY 
FUNCTIONALITY TO THE AAA MESSAGES 



TRANSMITTING, BY A HOME MOBILITY MANAGER 
(HMM) TO THE USER, THE INFORMATION VIA THE 

DATA NETWORK, THE SMM, AND THE ACCESS NODE 
USING THE TRUST RELATIONSHIP, WHEREIN THE 

HMM IS COUPLED TO THE HOME AAA SERVER AND 
IS LOCATED IN THE HOME NETWORK 
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